So far I've tried 4800, 9600 and 19200 baud, 8N1 RTU.

I need to stop and learn more about threading, I'm wondering if I'm doing something I shouldn't. I'm running the C program from a user button set to thread 5. I sprinkled debugging messages around the program and I examine them on the console window. Sometimes a printed text string will be split with other data inserted inside the string, as though some buffering and threading is happening and the outputted text gets slightly jumbled. I've tried to keep the printf debugging messages to 1 or 2 characters to speed things along. I doubt if it's related to my problem but I'm not sure.

I may try to hook up a second PC to eavesdrop on the communications on the rs485 bus. I read it can be very helpful but I've never tried it before. I do have a second rs232/485 converter that should work.

As usual, it's the simple things that are so maddening. LOL

thanks

--- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
>
> What Baud Rate are you using?  KFLOP can only receive characters at 56KBaud or less.  It is fixed at 8bits + 1 Start + 1 Stop bit.  The RS232 GND is common with Kanalog DC GND.
>
> Good luck.
>
> TK
>
>
>
> ________________________________
> From: bluetoad559
> To: DynoMotion@yahoogroups.com
> Sent: Friday, January 18, 2013 9:37 AM
> Subject: [DynoMotion] Re: Kanalog Modbus'ish attempt
>
>
>  
> Update: The rs232 'is' enabled. I rigged up an LED/resistor to see if the rs232 TX and RX bits were wiggling when a command is sent and they 'are.' The LED flashes on when commands are sent. Now I just have to figure out why the vfd isn't seeing them, or understanding them.
>
> Sometimes I even get back a response from the vfd but it's all F's/garbage. At least I have some bits wiggling now. :-)
>

I connected another PC to monitor the rs485 and it works great! The command codes coming from the Kanalog were fine, even the CRC bytes were ok.

The problem seems to be that every VFD command (frame of data) sent by the Kanalog is prefixed by a leading byte of 00. The C code ignores it and the CRC generating code ignores it but it does get sent. After deleting nearly every line of code in ModbusMasterVer1.c in order to find out what was generating this mystery byte, it turned out to be the line: EnableRS232Cmds(RS232_BAUD_9600);

Here's the code that remained and it generates a 00 byte on the rs232 every time the User button is pushed.

------------------
#include "KMotionDef.h"
#include "ModBusMaster.h"

void ModbusMaster_Init()
{
printf("Modbus Master Init\n");
EnableRS232Cmds(RS232_BAUD_9600);
DoRS232Cmds = FALSE; // turn off processing RS232 input as commands
}


main()
{
ModbusMaster_Init();
}

-----------------------------

I suppose if I leave the program in a forever loop and pass info to it occasionally there may not be a problem. All this is new to me and I'm not yet sure what's permissible in a thread. I grew up thinking infinite loops were a bad thing. LOL I've got more testing to do but it's looking up. :-)

I searched around looking for 'Threading101' info as it pertains to the Kflop environment. I was wondering if multiple 0ne-time functions could share the same thread number. Wondering if I 'should' use the same thread number to maximize execution speed. Should thread numbers be used sequentially ? etc. It took me hours of searching to find this little gem, I'll re-post it here in case others might search for it as I did. It's from here where Tom answered a question: http://tech.groups.yahoo.com/group/DynoMotion/message/6094

and it really REALLY helped me get my head around it as a newbie. Thank you Tom!
---------------------

Really the only thing that you need to understand is that two programs that ever need to be running at the same time need to be assigned to different threads. The KFLOP system Thread runs all the time in Thread #0. So Thread #0 may never be used. In a typical KMotionCNC system the Init.c program is usually assigned to thread #1 and runs forever. If other UserButtons (or MCodes) run C Programs that do something and terminate (Exec/Wait option) then these might all be assigned to use Thread#2. If your programs run for a longer time where a 3rd or 4th program might be Launched so they all overlap in time, then they must all be assigned to different Threads.

All Threads are killed (stop executing) when the Big Red Stop Button is pushed - except for thread #7. So use thread #7 for anything you wish to continue to run after a Stop.

---------------------

I suspect other newbs like me would benefit from having something like this tacked onto the multitasking help page. Possibly flashing. :-) I did spend a lot of time finding this. I searched here, CNCZone, the web, even searched the 226 page xilinx data sheet. I also learned a lot about threading steel in my searching. LOL This deserves a beer. :-)

--- In DynoMotion@yahoogroups.com, "bluetoad559" wrote:
>
>
> I need to stop and learn more about threading, I'm wondering if I'm doing something I shouldn't. I'm running the C program from a user button set to thread 5.
>